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(57) ABSTRACT 

Persistence of information and programming from one web 
page to another is gained by load ing an applet or an Active 
X object r epeatedly by addition of apple t or Active X object 
code to the HTML code of a plurality of web pages. The 
persistence is also spread, beyond the web pages that repeat- 
edly load the said applet or Active X object, by forming a 
pseudo-constructor with which an object, Riirh as ^ graphical, 
user interface , i s generated by the initial loading and execu - 
tion of the applet or Active X object, and persists even after 
the web page which loaded the applet or Active X object has 
been closed. In an exemplary application of the techniques, 
a shopping cart is generated that keeps track of the quantity 
and prices of items selected from a plurality of web pa^es. 
The cart operates without any interaction with the host 
server or other source of the web page s, apart from initial 
downloading of the applet or Active X object and final 
presentation of purchased items. Information about available 
items is also preferably hardcoded into the original HTML 
page, and not downloaded separately from the server. The 
techniques can also be used to cache database requests, thus 
avoiding the need for any server-client interaction beyond a 
first initial download. For example, this method of caching 
can be used to store, on the client, optional price updates to 
the products which are purchased in the shopping cart. 

23 Claims, 4 Drawing Sheets 
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SYSTEM AND METHOD FOR GENERATING 
PERSISTENCE ON THE WEB 

CROSS REFERENCE TO RELATED 
APPLICATIONS 

This application claims the benefit, under 35 USC 119 (e), 
of U.S. Provisional Application No. 60/153,232, filed Sep. 
13, 1999, and U.S. Provisional Application No. 60/174,709, 
filed Jan. 6, 2000. 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

The present invention relates, in general, to a system and 
method for generating programs associated with Internet 
web pages that can persist from one web page to another 
without requiring repeated downloading of the programs 
from a remote server, or the like. 

2. Description of the Prior Art 

The World Wide Web is generally considered to be largely 
stateless because one web page cannot transfer information 
to a page that is outside of its scope, or the scope of its 
parent. For example, programs or subroutines, such as JAVA 
applets, that are embedded in the Hyper Text Markup 
Language (HTML) code for a web page, can only be run in 
association with that page, and cannot be stored on a user's 
computer for subsequent use with other web pages. This 
restriction is currently bypassed, to some extent, in several 
ways. One way is to use active server pages (ASPs) on the 
host server that can generate pages dynamically, on the basis 
of information that persists on the server. For instance, 
MICROSOFT^ INTERNET INFORMATION SERVER 
can be used to generate active server pages that act as if they 
have memory. There is no intelligence, however, provided in 
the browser itself. 

As an illustration, consider a "shopping cart" example 
where items are offered for sale at a store site on the Internet, 
and a list of items selected by a purchaser (client) is 
generated as they enter their order. A central computer has 
a database of the items for sale, and pictures, descriptions 
and prices for each item. The items are assembled into web 
pages that are encoded using HTML, as is conventional. In 
addition, the web pages that display the items are each ASPs, 
because instructions are contained in these pages that will 
generate the final HTML page that will be sent to a client 
who wishes to place an order for one or more of the items. 
The central computer does processing, according to instruc- 
tions contained on the ASP, retrieves all of the required 
elements from databases, and assembles a page that the 
client computer's browser can read. Thus, the items are 
stored in the central computer, and central computer pro- 
cessing generates the page. As a result, the pages are usually 
in the form of grid-like, computer-generated lists. 

Suppose the client buys something on a page, by pressing 
a "button" on the web page. The button sends information to 
the central computer, which stores that information centrally 
and then generates another page, indicating what has been 
purchased. This new page is then downloaded to the client's 
computer, which displays the new page with its browser. 
Links are kept open at the central computer that wait for the 
client to enter additional purchase requests. If another pur- 
chase request is received, the central computer generates yet 
another page that contains the updated purchase 
information, and once again, downloads this page to the 
client's computer. Once the client finalizes their order, the 
central computer collects credit, address and other in forma- 
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tion from the client to conclude the transaction. Clearly, the 
foregoing procedure is demanding on the central computer's 
resources since it requires that the central computer generate 
and download an updated page each time another item is 
5 selected. 

Memory can also be maintained on the browser, through 
what are known as "cookies" that may be used to store 
name-value pairs on a client's computer. A cookie is a string 
of up to 2K of name=value pairs, separated by ampersands, 

10 such as Productl«jam&Product2«butter &Pricel = 
14&Price2=22.95. These cookies are used by JAVASCRIPT, 
which is a scripting language contained in HTML. In this 
technique, a program that is executed on one page tests for 
the presence of the name-value pairs in memory associated 

15 with a browser, and when it finds them, it assumes that they 
were placed there by some other program on a previous 
page, and it operates on the information. Each page contains, 
in its entirety, the code that runs on that page. It must also 
contain the code to store and to retrieve cookies. This is 

20 sometimes done on cheaper shopping carts, usually for very 
small merchants. 

In the shopping cart example, cookies work in the fol- 
lowing manner. A merchant's items for sale are located on 
a normal HTML page. The central computer does no 

25 processing, but simply delivers the page. On that page, there 
can be up to 200 to 300 lines of JAVASCRIPT code. It is 
meticulously written to display the items for sale, and to 
store cookies. A purchaser buys something by pressing a 
button. The code on that page looks to see if there is a cookie 

30 that indicates that the purchaser has bought something else 
previously. If so, the program retrieves the cookie, and 
displays the total sales, including previously selected items, 
as well as the currently selected item Then, this information 
is stored in a revised cookie. Now suppose that the purchaser 

35 jumps to the next HTML shopping page. That page has to 
contain all of the JAVASCRIPT code all over again, because 
there is no memory of the code from one HTML page to 
another. As with the previous page, the program then looks 
to see if there is a cookie, and if there is, it retrieves it and 

40 displays the sales from previous pages. Thus, although the 
use of cookies eliminates the need for the central computer 
to perform processing of the purchase information through 
storage of name^value pairs in the browser computer's 
memory, it is still necessary for each page to contain 

45 extensive JAVASCRIPT code, and this tends to place major 
restrictions on web page design freedom. 

Recent browsers, MICROSOFT EXPLORER 4 and 5 in 
particular, implement Dynamic HTML, which allows the 

5Q persistence of some variables on the browser. However, 
neither this limited persistence nor any of the other afore- 
mentioned techniques have yet reached the stage at which a 
particular program can survive from page to page on the 
browser, without any intervention from the server gathering, 

55 remembering and processing information. As a result, any- 
time the same program is to be utilized with each of a 
plurality of sequentially downloaded or accessed web pages, 
the program and any associated data must either be down- 
loaded from the server to the client with each page, or it must 

6Q remain resident on a server, and interact with each page, thus 
not only taxing the server's resources, but also substantially 
slowing the client computer's processing speed. 

SUMMARY OF THE INVENTION 

65 The present invention overcomes the drawbacks of the 
aforementioned techniques through provision of methods by 
which programs and data associated with web pages are 
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automatically stored in a computer's or other computing shopping site's server, which processes the order. It should 

device's memory for subsequent use in association with be noted that with this arrangement, the server is not 

other web pages. This is achieved through use of the inherent involved in the processing of the shopping cart information 

characteristics of a software engine, such as JAVA'S VIR- until the purchaser has finalized their order. As a result, 

TUAL MACHINE (JVM), that runs on the computing 5 substantial server resources are saved, 

device, and executes applets and other programs that are The second technique is employed to extend the persis- 

embedded in the HTML coding of web pages when they are tence 0 f a program generated object, such as a shopping cart 

loaded on the computer. More particularly, the present frame or other grap hical user interface, even when web 

invention employs first and second techniques by which a pages m loac j e d in the computer that do not contain any 

program generated object, such as a shopping cart, can be 10 re f er ence to the program which generates the object. In the 

generated by loading of a first web page containing the fi^ embodiment of the invention discussed previously, the 

necessary code for generating the object, and will remain, or program will not be reactivated if the next loaded web page 

appear to remain, generated as additional web pages are does not contain a reference or call to the program. Thus, the 

loaded on the computer. shopping cart will not persist if a client navigates to a web 

In the first technique, p rogram code is added to the HTML 15 page that is not associated with the shopping site. However, 
of each of a plurality of web pages that is loaded and the shopping cart can be made to persist by modifying the 
executed by the software engine to generate the object when ' program code in such a manner that the JVM or other 
a flrsi of the weo pages is loaded on the compute r. As is software engine will execute the applet or program upon 
conventional in JAVA programming, the program code loading of ah initial web page that contains the applet code, 
includes a tag that identifies the program by name and 20 but will de -couple the program from the web page so that the 
codebase so that if the software engine has already executed JVM will continue executing the program even when the 
the same program during a previous page load, the codebase W eb page is closed. This is achieved by using an indirect 
for the program, which is now resident in the computer's reference in the applet to a separate class that contains all of 
memory but in a suspended or inactive state, will be the necessary code to run the shopping cart or other pro- 
accessed to reactivate the same program, thereby 2 5 gram. When the applet is executed by the JVM, the shopping 
re-generating the object without reloading the program from C art program contained in the separate class is also executed, 
the HTML code of the web page. but now operates independently of the applet. This is 

The key to the first technique is that a number of variables because when a web page is closed or unloaded, any applets 
are defined in the program as static variables that can be referenced in the web page will be suspended or deactivated 
modified during execution of the program. Static variables 30 by the JVM as discussed previously. However, since the 
in JAVA have the characteristic that they will be remembered separate class was purposely defined not to be in the applet 
by the software engine even if the program is suspended or itself, the JVM will continue to run the shopping cart 
rendered inactive by loading of another web page. Thus, in program even after the page has been closed. As a result, the 
a shopping cart example, if the identities, quantities and shopping cart will persist even when the client surfs to other 
prices of selected items are defined in the shopping cart 35 web pages that are not related to the shopping site, 
program as static variables, whose values can be changed i n both embodiments of the invention, a number of 
through selection of items from an associated web page, then optional features are preferably employed. For example, 
the values of these variables will remain stored by the JVM execution of the applets or programs can also trigger down- 
in memory along with the rest of the program code when loading of a separate database that can be accessed during 
another web page is loaded. If this new web page then also 40 execution of the program. This arrangement is useful, for 
includes a reference or call to the same applet or program, example, for downloading price updates that can be accessed 
the JVM will reactivate the shopping cart program along by the shopping cart program In addition, each web page can 
with the values of the static variables as they were left in the be modified to load different operational parameters with the 
last page. The result is that through this repeated reactivation program so that the program will run differently with dif- 
of the program and static variables stored in memory by the 45 ferent pages, even though the exact same program code is 
JVM, the shopping cart can be made to appear as if it being used. 

continually persists as a purchaser surfs through a group of nt foregoing methods thereby eliminate the need for a 

shopping site web pages. Further, there is no need for the remote or central server computer to store the program data, 
purchaser's or client's computer or other device to commu- ■ and l0 gene rate program-containing pages each time a new 

nicate with the shopping site server until they are ready to 50 web page is requested. Unlike the prior art technique of 

submit their complete order for processing. using coo kies, the effective memory inherently created by 

Thus, in the shopping cart example, as a purchaser or the JVM goes far beyond name=value pairs, and extensive 

client selects items from a page, these items are added to the JAVASCRIPT coding on each page is unnecessary. Also, 

shopping cart, thus modifying the various static variables unlike the prior technique of using ASPs, the server is not 

that define the elements of the cart, such as item ID, quantity 55 bogged down with computationally intensive processing, 

and price. When the client now navigates to another web thus freeing up resources. As a result, the shopping cart 

page containing information on additional items for sale, the program or other program can be hosted on a very simple 

shopping cart program is temporarily suspended along with cent ral server, and yet it still has the design freedom of the 

the current values of the static variables. However, as soon most expensive machines and sites. 

as the next page is loaded, the JVM detects the applet 60 ™ 

identification information in the new page's HTML code, DESCRIPTION OF THE DRAWINGS 

and immediately reactivates the shopping cart program The features and advantages of the present invention will 

along with the static variables as they were last left. This become apparent from the following detailed description of 

process is repeated over and over as the client surfs from a number of preferred embodiments thereof; taken in con - 

page to page. Once the client is finished with their purchases, 65 junction with the accompanying drawings, in which: 

the final shopping cart information can be sent along with FIG. 1 is a "screen shot" of a web page over which is 

the client's other necessary identification information to the displayed, a shopping cart frame that is an example of the 
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type of object that can be generated using the techniques of order through activation of the frame buttons 16, even after 

the present invention; they have navigated to other web pages that are not even 

™^ - . , . c . lU . associated with the shopping site. 

FIG. 2 is a schematic diagram of a computer system that rr & 

can be employed to implement the preferred embodiments 5 FIG. 2 shows a networked computer system 30 that can be 

of the present invention; configured to implement the preferred embodiments of the 

~ . a u . -ii » .u n * *u * invention. The computer system 30 includes a first server 32 

FIG. 3 is a flow chart illustrating the overall steps that are t * 3 P , , , , , 

i a- « * t _ a u a * e*u • «. that serves as a first source of web pages. It should be 

employed in a first preferred embodiment or the invention to . , , , , . . „ 

/„ . . . , ... , understood, that while the server 32 is typically a remotely 

repeatedly reactivate a program associated with a plurality . , * , . ... 

f . j 10 located computer that communicates with other computers 

of web pages; and , . : . T . , 

r ° or devices via the Internet, the server 32 can also be a local 

FIG. 4 is a flow chart illustrating the overall steps that are storage means, such as a hard drive, CD-ROM, etc., silo and 

employed in a second preferred embodiment of the inven- can be accessed through other than the Internet, such as 

tion to generate a program object that is associated with one through an Intranet or LAN. 

or more web pages, but is designed to remain active after the 15 

web pages are no longer loaded in a computer or other ^ 32 includes a memory 34 that contains a 

computing device on which the present invention is imple- plurality of HTML encoded web pages, and at least a first 

mented. directory for storing programs, such as JAVA applets and 

Active X objects that are referenced by the web pages. In 

DETAILED DESCRIPTION OF THE 20 addition, the memory 34 can store databases that can be 

PREFERRED EMBODIMENTS downloaded in conjunction with the execution of the 

programs, such as price update databases in the shopping 

Turning now to a detailed consideration of a number of cart application, for example, 
preferred embodiments of the present invention, one pre- . _ - « ,i 
ferred application of the present invention is the generation 25 . A cjient e nrnpntfir worksMlon . 36, . such ffl a , PC fir the Mg 
of a "shopping carl" for use with an Internet shopping site * pro " dcd that reccives information from the server 3 2 
in which a plurality of web pages are available that provide through a comm unications link 38. The workstation 36 
descriptions of items for sale, and enable the items to be includes, as is conventional, a processor 40, a keyboard 
selected and added to the purchaser's shopping carl. The and/or other input devices 42, an operating memory 44 (i.e., 
shopping cart application will be employed to demonstrate 30 RAM), a storage device 46, such as a hard drive or 
the operation of the preferred embodiments, although it will CD-ROM, and a video display monitor 48. In a preferred 
of course be understood thai the techniques of the present embodiment of the invention specifically for use in access- 
invention can be used with any program or application that ing web pages from the Internet, a browser application 50 is 
is run in association with one or more web pages. loaded in the memory 44 for facilitating loading and viewing 

With reference to FIG. 1, a screen shot of a sample web 35 of "™ L w< * P a S es - ^ is also conventional, the browser 

page 10 is illustrated, on which a shopping cart frame 12 is W^tton 50 incorporates a software engine 52, such as 

overlaid. The web page 10 includes a plurality of buttons" JVM - that interprets and runs applets, Active X objects, and 

14 that can be actuated with a mouse or other input device, other programs that are referenced in one or more loaded 

as is conventional, to select any of a number of items for we ' 3 P a S es - — 

purchase. The shopping cart frame 12 also contains a 40 u should be understood that the computer workstation 36 

number of buttons 16 that can be employed for various could be laccd b other suita51e computing device if 

.purposes as illustrated such as increasing or decreasing the desired ^ Qnl irement fe that the device inchldes 

quantity of an item and submitting a final order for check- ^ for , oadi wefa ^ a soflware 

out. In addition, the shopping cart frame 12 includes a r . . ° , . , , 

u c a" i • a i io c • ,l 45 for executing programs associated with the web pages, 

number of display windows 18 for showing the quantity, ~ , c . . • - . , , . . T . 

. , ... i ■ c.u i * a ■* i j • i_, . I Examples of such alternative devices include basic Internet 

identity and price of the selected items, including a subtotal • »• . • i , AV a a . l a • 

r * c *u a communications terminals, JAVA chips, and other devices 

of the current price of the order. . - 4 . T ' t . i ♦ * u n 

that can interface to the Internet or to an Intranet, such as cell 

As will be discussed in greater detail later, the shopping phones, PALM PILOTs, etc. 

cart frame 12 is generated by a program or subroutine, such 50 T . , . ... c , r . 

t a\ ta. i * a *■ v i • * *u * • u In the shopping cart implementation of the preferred 

as a JAVA applet or an Active X object that is run by a . , r \, & . r *i_ i . .* a 

software engine, such as JAVA'S VIRTUAL MACHINE emb ° duncnls > the operator of the workstation 36 sends 

/-w-\ t\ t\ . i m iii* , information, when the operator wishes to finalize a purchase, 

(JVM), when the web page 10 is loaded onto a computer or 4 , . « r . . , - A t ; . 

\. 4 - j i i m 4 . r i through a second communications link 54 to a central server 

other computing device. In accordance with the preferred m , - & ™ . ., , 

u a- * r .i_ > - „• *i_ l. • * 56 for processing. This arrangement avoids the need to send 

embodiments of the present invention, the shopping cart 55 , . \. . & . r a * • * a- - . , 

. , • a * *.u ii* c substantial amounts of data in two directions through the 

program is designed to run in conjunction with a plurality of . . , T . . t» t , 

r r . 4 r . , . . , c i t a * * c communications links 38 and 54, It should be understood, 

web pages, without losing track of the selected item infor- , ..... ^ . ™ ,j . ^ r 

. rr l * lL however, that the first server 32 could be used for order 

mation as a purchaser surfe from one web page to another, rocessin as well 

and without requiring repeated reloading of the program. In processing as we 

addition, in accordance with a second preferred embodiment 60 To implement the preferred embodiments of the present 

of the invention, the shopping cart frame 12 can be gener- invention, all that needs to be done is that the HTML code 

ated upon loading of a first web page, but will persist as long for one or more web pages be modified with additional lines 

as the software engine is active, including after the page that of code. In an example designed specifically for generating 

triggered generation of the shopping cart frame 12 has been a shopping cart with JAVA applets and JAVA'S Virtual 

closed or exited. Ilie program that generates the shopping 65 Machine, the <BODY> tag in any HTML web page or 

cart frame 12 thus runs independently of the web page, thus document in which persistence is required is replaced by the 

enabling a purchaser to make further modifications to their following lines of code: 
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<BODY onLoad-"v( )'*> 

<Ai , PLin" code«app .class height" 1 width=l id«app name-app archivc»"app^ip"></APPLCT> 
<SCRIPT LANGUAGE=javascript> 

function buy(a,b,c,d){documcnt.app.prod(a I b,c,d)} 

function v( ){documcnt.app.sct Version(ncw Str in g( navigator. appName),ncw String(navigator.app Version))} 
<^SCRIPT> 



The inclusion of this 'boilerplate code* into an HTML 
page alters it completely into something which has memory, 
maintains a shopping cart, and has access to a database 
cache. The shopping cart itself detaches from the launching 
HTML page, and operates for as long as the browser is 15 
active. This occurs without any interaction with the server 
32, beyond the initial loading of the HTML web page or 
document and its associated applet. 

The reason that the persistence works is because JAVA 
applets are in an active state for as long as the HTML page 2Q 
in which they are loaded is on the browser screen. When a 
jump is made to another page, then the applets that were 
loaded on the previous page become inactive. However, 
unless there is a shortage of memory, they are not unloaded. 
Whenever the browser returns to an applet's page, then the 
particular applet for that page is not usually reloaded, but 25 
rather it is changed from an inactive or suspended state back 
again to an active state. Static variables that were set in a 
previous active stage are remembered during times of 
inactivity, and can be accessed when an applet again 
becomes active. Now, if a page loads an applet with the same 30 
name as one that was loaded by a previous page, and if this 
involves a relative (in contrast to an absolute) call to the 
same codebase, then the applet for the previous page 
becomes active again — just as if it had been called by the 
previous page. A new instance of the applet is not usually 35 
loaded. This feature can therefore be used to store informa- 
tion between HTML pages. 

An applet, however, contains program code as well as 
variables. Persistent processing can therefore be carried out 
on the persistent memory. A program can thus be written that 4Q 
appears to live on from page to page — it is continually being 
altered from an active to an inactive and then again to an 
active state and given access to its previous memory. 

If an applet with the same name but a different codebase 
is loaded, then, for security reasons, it is assigned a new 
address space. The same shopping cart code, even when it is 45 
run simultaneously on separate commercial sites from the 
same browser, can therefore develop and maintain distinct 
shopping carts for the separate merchants. 

If an HTML document in a subdirectory of a site wishes 
to participate in the persistence, then it is sufficient to add the 50 
line CODEBASE- ... to the APPLET tag. This technique 
can be extended throughout a directory and subdirectory 
structure, so that persistence spreads freely throughout any 
given site. Alternatively, it is often possible to access the 
applet absolutely, as in CODEBASE=http://www.myserver/ 55 
myAppletDirectory as long as the applet and the HTML 
pages are located on the same server. This absolute call is 
then treated as relative. The boilerplate code now becomes 
independent of directories and sub-directories. 

Since Active X as implemented in MICROSOFT'S 60 
Dynamic HTML is based in the JAVA language, it turns out 
that it can also generate persistence. The applet has in fact 
been successfully ported to an Active X object. The 'boil- 
erplate code/ in the previous section, may thus be altered so 
that it is an <OBJECT> that is loaded rather than an 65 
<APPLET>With a few minor adjustments, there is the same 
functionality. 



The applet or object that is continually being reloaded 
does not need to be entirely identical from page to page. In 
particular, it may have different parameters, as expressed in 
varying <PARAM> tags under the <APPLET> tag. Clever 
use of this freedom with parameters can enable massive 
changes in the classes that are instantiated from one page to 
the next, and thus generate genuine alterations in the code 
itself The program can vary in ways that would never be 
possible if it were not being continually reincarnated. 
Alternatively, Boolean variables can be set or cleared in the 
applet code which also determine ways in which the applet 
or Active X object re-incarnates itself. 

Since persistence is linked to the JVM, and not to the 
HTML, it is not necessary to load an applet or object into 
every page of a site in order to gain persistence. It is enough 
to load the applet or object into those pages in which access 
to the accumulated information is necessary. Browser 
mechanisms, and the functionality of JAVA, make sure that 
the information is maintained — for as long as memory 
permits — until it is needed, even through extended access to 
pages or sites which know nothing about the applet or 
object. 

Of course, if the applet is inactive, and memory is needed 
for other JAVA programming, then the virtual machine will 
overwrite the program. There is room, therefore, for only a 
limited number of programs that use this technique. 

It should also be noted that persistence of memory 
throughout other pages or sites is not a security issue 
because an applet or Active X object is resurrected — or 
made accessible to other programs — only if it resides at the 
same codebase, or at some relative offset. 

The second method for developing persistence between 
HTML pages will now be discussed. If one looks at abstract 
classes in JAVA, one notices that they are tied very closely 
to the JAVA virtual machine. If they could be instantiated, 
then certainly they would persist — programs could then be 
remembered along with data, even when the applet was 
inactive. However, abstract classes cannot contain construc- 
tors. Suppose, however, that applet code is composed solely 
of pointers to static variables defined in some abstract class. 
Suppose further that static components for a frame (buttons, 
etc.), as well as the static name of the frame itself, are also 
defined in the abstract class. Then, suppose that unit() in the 
applet calls a static function in the abstract class which 
instantiates the static frame and assigns the static compo- 
nents to it. It then sets a flag in the abstract class that tells 
it not to do this again. One now has a kind of pseudo- 
constructor for the abstract class. The resulting frame, and its 
components, are tied, through the abstract class, to the JVM 
itself, and they persist from HTML page to HTML page, 
even when the applet is not being loaded. The applet that 
originally launched both the frame and the abstract class 
may itself move back and forth from an active to an inactive 
state, but this makes no difference to the frame itself, for it 
is no longer dependent upon the applet. It turns out that if 
one uses the same kind of pseudo-constructor in a normal 
(not abstract) .class, then one will also generate a frame 
which breaks free of the launching site and persists indefi- 
nitely. 
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Now, how are events enabled within this 'terminate and and displays this in the shopping cart frame or form. If it is 

stay resident* frame — so that it will carry out actions when not, then it uses the number that is hardcoded into the HTML 

'off site'? It is done in the following manner. Events must be as 'itemPrice.' Again, this involves no interaction with the 

caught in the frame itself, but all variables and interrupt host server. The fact that everything occurs on the client, and 

methods are contained as static variables and static methods 5 can use the full power of the client's processor, means that 

in the abstract class. The frame event handlers simply make database access involves no noticeable delay, even when the 

jumps to these static variables and methods. A program has database is quite large. The 'itemlD' is the key and must 

thus been created that lives beyond the page in which it was al be m ^ , itemPrice > ^ m t stri 

launched, remembers data that is collected from page to ^ {i ^ men me database musl al be and {{ 

page for as long as a page accesses the launching applet 1Q must C0Qtain < itemID , and a correspondi <it em Price.' 

through a relative call, and carries out event handling within _. , , . . . . . . 7 , . , . . 

the frame itself on applet data, when off-site. ^^5!^^^™°^^ § W 

„ a u , • t7Tr>c 4 a a • *u ♦ MICROSOFT ACCESS, and can thus be integrated into any 

The flow charts in FIGS. 3 and 4 summarize the two . . , , , . ' . t " i t r * 

c ... c c large-scale database. It is a two-column table in text format, 

foregoing techniques for creating persistence of a program J i i_ j • j i_ • , • 

• ■ . 1 , . * r c . r, T ^ , and can thus also be designed by a novice operator using a 

object, such as the shopping cart frame 12 in FIG. 1. as 1<: . ™ « . J , , r , , 

\.\ , j . « i , v.- 15 simple text editor. To be recognized by the applet or object, 

multiple web pages are loaded by a browser application, or . r , t , i * t - . i_ * j ^ 

i im ? n . . i iL c f . *™ c the database in this implementation must be stored on the 

the like. With reference first to FlG. 3, the first step 100 for , . ,£* 

. . .1- * l • *i_ i. merchant s server in the same directory as the applet or 

implementing the first embodiment, wherein the same applet , , . t . « j * j * * , u i . 

. r ii i * i i object, and it must be called update.txt. When the applet or 

is repeatedly reactivated, is to add applet code and an /. a * i ^ j u i •* u i c 

. . t f c . J 4 4 . „™. T c u c i r, c u object is first loaded by some particular page, it checks for 

identification tag to the HTML of each of a plurality of web ?n iL J C , J . . r / «, 

xt * * ♦ 1 m a . f .u u • , , , 20 the presence of this file in its codebase directory. If the file 

pages. Next, at step 102, a first of the web pages is loaded . - r , . . 4 . . . « ■* j ■* *i_ 

T ° *• j ■ j«u ■ . -iu *u is found, then the applet or object loads it, and it then 

into a computing device, and the program is executed by the ♦ ■ u {IT r • * u / t <u- 

Ca . a* * 1A / tL b , t . -Li generates a cache, on the client, for subsequent pages. In this 

software engine. At step 104, the static variables are r . . ' . u ■ * o* * ■ L * 

... , , f J . , j X. u ' * a * * implementation, this cache is a static String in an abstract 

modified, if desired, and the web page is exited at step 106, TA f 7A , , . . ™ 4 . , & ... 

iL . f iU » • /. . JAVA class, and it persists. The string may be well in excess 

thus suspending activation of the program and maintaining nu . \ iU r , tU . . ' . Ann™ 

. * j , t t . " U1 6 . t . t . & 25 of 1 Meg in length, and could thus include more than 40,000 

the program and the static variables in the computing • ir*u j * u • u * *u i * u- * 

, . , xt * . , ,ao j c u revisions. If the database file is absent, the applet or object 

device s memory. Next, at step 108, a second of the web . ... „ . i* j o i 

..j,- 7 ,' • ' • . j L r remembers this as well — in our case as an altered Boolean 

pages is loaded, and the program is reactivated, by vutue of . U1 . . u TA , /A , KT - . r . . . 

f, & . r . % . . im Mj j r variable in the JAVA code. No further server-client mterac- 

the program identification information in the HTML code of . „ ^ , 

if .... • i r.i. . * Li tion is attempted, or necessary, 

the web page, with the previous values of the static variables 30 r J 

intact. Steps 104, 106 and 108 are then repeated for each 0nce ^mPrice' has been checked with the (optional) 

subsequent loading of additional ones of the web pages. database, which is cached on the client, then the applet or 

With reference to FIG. 4, the second embodiment of the ob }^ whi ^ h also r£ f d f ? n the cli f l > P| a f s th f e result in 

invention also starts with the addition of the object gener- a frame or fo ™ on the des ^ to P window Sales ^formation 

ating code at step 200 to at least one web page that will 35 &S " ls r i tored f a f Uc ^ in th u e J ^ VA 

initiate generation of the object. In this instance, all of the code and it persists. The result of the purchase can therefore 

static variables that are employed to generate the object, are be j h P "° r ^ ch ^ and a m 8 total devel " 

defined in a class, e.g., abstract class, that is referenced by ope an sp aye ' 

the applet, but not actually contained in the applet itself. Since cumulative sales information has persistence, it is 

Upon loading of the web page at step 202, the software 40 P os sit>le to alter previous purchases without going back to 

engine executes the applet at step 204. This in turn creates tne P a S es on whicn tne y were presented, and without inter- 

a call at step 206 to the class containing the object generating actin S in a °y wa Y with the hosl server. For example, 

program, which thus causes execution of the program and referencing again FIG. 1 and the buttons 16 in the shopping 

. generation of the object at step 208. Next, at step 210, the cart frame 12 > the <up ' and 'DOWN' buttons allow scrolling 

web page is unloaded, thus terminating execution of the 45 through the list of purchases, and the 'MORE' and 'LESS' 

applet, but the object generating program continues to run buttons allow prior purchasing decisions to be altered, 

because it operates independently of the applet. If 'CLEARCART' is pressed, then, in one version of the 

Returning now to the shopping cart example, a non- implementation, the purchase Silo buffer is cleared, this 

commercial site is altered into a commercial site through the persists, and the applet or object, in its next incarnation, 

inclusion of the 'boilerplate code* into the HTML of all 50 chooses to bring up only a stub of itself. Full instantiation of 

pages that wish to present items for sale, A specific item is the purchase frame or form occurs only when a purchase is 

then offered for sale by including an onClick«"buy made, and for as long as there are items in the purchase 

( < itemiD , , < itemName\ £ itemPrice\ buffer. Since applet or object code is itself cached by most 

'itemShippingProcedures')" event handler into any page browsers, in a separate memory area, this means that there 

object which is able to support it— this may be a button, a 55 ^ essentially no 'overhead* involved in carrying the applet 

diagram, some region of an image, or even a JavaScript or object stub from one page to the next— navigation is 

program When the client operator triggers an event in this rapid, with no noticeable delay. 

object on his browser, a call is made by the event handler to Another version of the implementation generates a frame 

the applet or object which was loaded into the page, and the which is linked to an abstract class, and thus independent of 

applet or object adds the item to a shopping cart frame or so the applet and the particular HTML page. 'CLEARCAR^in 

form which this applet or object brings up whenever a sale this implementation simply makes the frame invisible. There 

is made. None of this involves any interaction whatsoever is now no additional delay whatsoever between HTML 

with the host server. pages, for one is dealing with transitions between active and 

When the 'buy* event is triggered by the browser operator, inac tive of an applet stub which is less than 1 K in size, 

the applet or object checks to see whether an item with ST When the client operator is ready to finalize his purchases . 

'itemlD' is located in a cached database on the browser. If I then, in a preferred implementation, he presses 'CHECK- 

it is, then it assigns the associated cached price to the object, / OUT ... * This sends the purchase information, as name- 
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value pairs appended to a hard-coded HTTP address, to a 
central server that is equipped to ask for name, address T and 
cr edit-card information. The codebase of the applet or object 
\ is also included — this is used to check that the merchant's 
1 site has registered with the central server, and that it is 
/^au thorized to do business. 

In one implementation of CHECKOUT . . . \ the program 
which is linked to the abstract class breaks into the JAVA- 
SCRIPT interpreter — it does not matter which HTML page 
is presently loaded — and jumps to the central server loca- 
tion. 'CHECKOUT . . . ' can therefore be carried out from 
anywhere. 'HELP* becomes 'HOME', and jumps to the 
merchant's home site. However, this implementation 
requires the use of MAYSCRIPT in the applet load, as well 
as JSObject classes. Another version supports a 'CHECK- 
OUT . . . ' only from the merchant's home site — this requires, 
a lower security clearance, and appears to be universally 
enabled. When the 'CHECKOUT . . . ' button is pressed, the 
cart is automatically cleared. Pressing ' RESET* , however, 
brings the information back, in case the user wishes to 
change his mind. 

In the preferred implementation, one of the fields in the 
'onClick=buy(a,b,c,d)' event handler is a string that encodes 
every possible variation of tax and shipping instructions. 
This information is passed, when a purchase is made, to the 
applet or object, which in turn passes it through unaltered to 
a central server, when the order is finalized, and the central 
server processes the order accordingly. 

With reference now to specific code examples that will 
implement the embodiments of the invention, the following 
code will place a frame on a web page, and then save its 
position as it is moved, so that it appears at the altered 
position when a new page is loaded. This demonstrates 
persistence. 
1 . An Applet Example 



10 



Compiling this code will generate the two files Appletl.class 
and Constants. class. 

Place the following code in HTML Page 1: 



<HTML> 
<HEAD> 
</HEAD> 
<BODY> 

opplet code-Appletl. class name«App!etl width=l 

height-l> </appIet> 
<A HREF-"Page2.htm">Page2.htm<^A> 
</BODY> 
</HTML> 



15 



20 



25 



Place the following code in HTML Page 2: 



<HTML> 
<HEAD> 

<TITLE></nTLE> 

</HEAD> 

<BODY> 

opplet code -Appletl.class name=Appletl width=l 

height- 1 id-Appletl> </applet> 
<A HREF-"Pagel.htm">Pagel.htm</A> 
</BODY> 
</HTML> 



When the applet is loaded, method init( ) is called. This 
creates a frame, and places it at the (x,y) position defined by 
variables framex and framey. A look at class Constants tells 
us that these are initialized at 225 and 150 respectively. 
Suppose that while Pagel is up, the user moves the frame. 
Method stop( ) is called automatically when Pagel is left by 
the user, and this determines the (x,y) position to which the 
frame was moved by the user, and remembers it by changing 



import java.awt*; 
import java.applet.*; 
public class Appletl extends Apple t{ 
public void init( ){ 

if(Contstants.frame = null){ 

Consants.frame = new Frame( ), 

Constants. frame. reshapeCCint)Consants.framex.intValue( )Xint)Constants. framey. intValue( ),300,300); 

} 

Constants.frame.show( ); 

} 

public void stop( ){ 

Constants.framex = new Integer(Constants. frame. bounds( ).x); 
Constants.framey = new Integer(Constants. frame. bounds( ).y); 
Constants.frame dispose( ); 
Consants.frame - null; 
} 

} 

abstract class Constants{ 
static Frame frame; 

static Integer framex - new Integer (225); 
satic Integer framey = new Integer(150); 

} 
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variables framex and framey. When the page is reloaded, compiler and saved as HTML Page l.htm. Notice that we 

method init( ) is called again. It seems obvious that the frame have inserted, into the automatically generated code, a 

should be placed again at coordinates (225,150), as defined hyperlink to a Page2.htm. 
in class Constants. That is the curious thing, however. The 
values of variables framex and framey, when a reload 
occurs, are those set by method stop( ) when the previous 
page was left. The initialization in class Constants is ignored 

by a reload. Why? The program is not being restarted; it is <TrrLE></rrTLE> 

simply being re-activated. That is the essence of persistence </head> 

as generated by applet reloading. 10 <body> 

There will be stability problems with the frame in some <object 

, « • • ■ . . ai . hcightaO width=0 . . . VIEWASTEXT id«OBJECTl> 

browsers. This is associated with the Abstract Windows < PA ram name-_codeclass VALUEoClassi> 

Toolkit, and is not linked to persistence. The instability is <param name-CABBASE VALUE=Project3.CAB> 

present even when the applet is not being continually </object> 

reloaded, and is caused by the fact that the applet must is <a HREF-"Page2.htm">Pa g c2.htm</A> 

interact with a peer, which does the actual work of con- </htmi> 

structiog the frame. The instability is removed in three ways: . 

the first is to adjust the order of frame operations so as to 

minimize pressure on the peer. The second is to follow every £ Page2.htm is produced by copying the contents of 

frame operation with a call to pack( ). This appears to place 20 Pagel.htm into an empty HTML page, naming this said page 

a modal stop on further execution until the peer- has com- Page2.htm, and altering the hyperlink to Page2.htm, in the 

pleted its task. The third is to introduce delay loops at critical said copied code from Page l.htm, into a return link to 

points. For instance, one might define the method pause Pagel.htmn: 
(200), in which pause(time) is defined as follows: 

25 



<HTML> 



void pause(int timc){ < J55 A ^ > 

long startTime - Sy stem. currentTime Mil lis( ); <TH LE></1H LE> 

while(System.currentTimeMillis( ) <startTime + time){ </HEAD> 
//infinite loop:time slicing creates a pause to give the peer an 30 < BODY> 

opportunity to finish <OBJECT classid="java:com.ms.wfc.html.DhModule" 
| height=0 width-0 . . . VIEWASTEXT id=OBJECTl> 

J, <PARAM NAME=_CODECLASS VALUE=Classl> 



cPARAM NAME=CABBASE VALUE=Project3.CAB> 

Notice in the applet code that the frame name is defined </object> 

in the abstract class Constants. This is absolutely essential 35 ^HREF-"Pag e i.hLm">Pagei.htm</A> 
for stability. Notice also that the class Constants is never </html> 

instantiated. 

2. An Active X Example 



import com.ms.wfc.html.*; 
import com.ms.wfc.ui.*; 
public class Classl estends DhDocument{ 
public Qassl( ) { 

if (Constants, form - null){ 

Constants. form - new Form 0; 

Constants, form.setBounds ((in t)Constants. fornix. in t Value ( ),(ui)(Constants.formy. int Value ( )),300,300); 

Constants, form .set Visible(true); 

} 

Constants.form.bringToFront( ); 

public void dispose ( ) { 

Constants.formx = new Integer(Constants.form.gctBounds( )jc); 
Constants.formy = new Integer(Constants.form.getBounds( ).y); 
Consants.form.dispose( ); 
Constants. form " null; 
super.disposef ); 
} ■ 

} 

absracl class Constants! 
static Form form; 

static Integer fornix - new Integer(225); 
static Integer formy - new Integer(150); 
> 

This code is interpreted by Microsoft Visual J++ Version 6, In contrast to the applet example, which uses the Abstract 
and used to form an Active X object which will be loaded by 65 Windows Toolkit, there appears to e no stability problem at 
the following two HTML pages. The first, or something all in the Active X implementation of persistence, which 
similar to it, is generated automatically by the Visual J++ uses Windows Foundation Classes. This demonstrates 
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graphically that persistence can be used to generate very 
dependable code. 

The previous two examples can be tested in the following 
manner, 1) Place all relevant files into the same directory. 2) 
Load Page 1 into a browser. 3) Use the mouse to move the 
frame (or in the case of Active X, the form) to a different 
location. 4) Use the browser to jump to Page 2. Notice that 
the frame does not come up in the original location but rather 
retains its new position. 5) Use the browser to jump to an 
unrelated page and then reload either Page 1 or Page 2. You 
will notice that the frame returns and maintains its latest 
position. 6) Repeat steps 3) to 5) as often as you wish. 
3. A Pseudo-Constructor Example 

Create the following applet: 



import java.applet.*; 
public class app extends Applct{ 
public void init( ){ 
ShopPancl.init( ); 

} 

> 

import java.awt.*; 
import java.awt. event.*; 

public class ShopFrame extends Frame implements ActionListener{ 
void formPanel( ) { 

add(ShopPanel.counter); 
ShopPanel.counter.addActionListener(this); 

} 

public void actio nPerformed(ActionEvent e){ 
ShopPanel.increment( ); 

} 

} 

import java.awt.*; 
public class Shop Panel { 

static ShopFrame ShopFrame = new ShopFrame( ); 

static Button counter = new Button("Ctick"); 

static int r « 0; 

static void formPanelElements( ){ 

shopFrame.setBounds(200,200,100,100); 

} 

static void initf ){ 

formPanelElements( ); 
shopFrame. form Pa nel( ); 
ShopFrame .show( ); 

} 

static void increment ( ){ 

counter.setLabelfnew Integer(r).toString( )); 
r++; 
} 



} 



Place it into the following HTML page: 



<HTML> 
<HEAD> 
</HEAD> 
<BODY> 

<applet code=app.class name=app width- 1 height-1 

VIEWASTEXT></applet> 
</BODY> 
</HTML> 



Notice, in this code, that neither applet *app' nor Frame 
'ShopFrame' contains any variables at all. All variables are 
contained in the class ShopPanel. The applet, in its method 
init( ), refers to ShopPanel, which in and of itself forces all 
of ShopPanel's declared variables, all of which here are 
static, to be instantiated. In particular, ShopFrame and 



objects in ShopPanel. The next call is to shop Frame, which 
now exists, and has defined characteristics, and in particular 
to its method formPanel( ), which takes the frame elements 
defined in ShopPanel, and sets them into shopFramc, which 

5 is also defined in ShopPanel. Event handling can now be set 
up, in shopFrame *s formPanel( ). Events are caught in 
shopFrame, but the event handlers are all located as static 
methods in ShopPanel. Notice that this structure is not 
dependent upon the applet at all — there is a call from 'app' 

30 to ShopPanel, but nothing from ShopPanel back to applet 
*app\ The frame shopFrame, which is created indirectly by 
the applet through its reference to ShopPanel, in fact knows 
absolutely nothing about its parent — it is aware only of the 
class ShopPanel, which is not being instantiated. When page 

35 transfers are made, it is the applet which is altered from 
active to inactive — notice how short it is, and how little time 
will be required to reload it. The frame doesn't change at all; 
it simply sits there, and watches as you browse. 

Let's look now at what our example does. The applet 

20 indirectly creates a frame. Clicking this frame increments a 
number. (there may be problems in some browsers — we are 
not including minor tweaking elements, composed solely of 
standard JAVA, that solve these * glitches'). Moving away 
from the HTML page does not destroy the frame — rather, it 

25 continues to operate as a kind of 'terminate and stay resi- 
dent' web program. Notice that the frame now maintains its 
position from page to page automatically, without any user 
intervention, unlike the previous two examples. This is 
because it is independent of what happens to the pages — 

30 when created it is tied to the JAVA virtual machine, through 
the static variables, and then never destroyed. This demon- 
strates that we have moved a stage further in establishing 
persistence. Since the frame is only created once, there are 
none of the stability problems that were previously associ- 

35 ated with the Abstract Windows Toolkit. Transition between 
pages is essentially instantaneous; whenever access to the 
underlying HTML is desired, then the very small source 
applet is simply reloaded on that page. It provides the link 
to ShopPanel, from the underlying HTML, 

40 Incidentally, if you look closely, you will notice that 
ShopPanel this time is not an abstract class. A pseudo- 
constructor for an abstract class must follow a very specific 
initialization procedure in order to work. It turns out that if 
the same sequence is followed within a normal class — using 

45 the same static variables and static methods — then this also 
leads to an object that 'lives forever.' However, a normal 
class can contain a constructor, and thus it can do more 
things. 

The two methods for creating persistence (reloading and 
50 pseudo-constructors) cooperate beautifully. The shopping 
cart, for instance, is created once, and then never destroyed. 
Applet reload gives it continuing access to the underlying 
HTML, through JAVASCRIPT and LiveConnect, and 
through the applet lifecycle, which can pass current context 
55 information to the persistent class. Creation of the shopping 
cart can occur on any of the pages that are being reloaded — 
one simply sets a Boolean variable 'firstTime' to true in the 
initialization statements in ShopPanel, and when the frame 
is created, one resets it to false. The change in the variable 
60 is remembered at a reload; the frame is created only when 
'firstTime' is true. 

Returning once again to FIG. 2, the shopping cart embodi- 
ment of the present invention preferably operates in the 
following manner. At least some of the web pages in the 



counter are formed. The applet's life cycle then calls init( ) 

in the applet, which transfers the call to init( ) in ShopPanel. 65 server 32 each contain a relative call to applet app.class, 

ShopPanel's init() calls formPaneElements() in ShopPanel, located in a first directory on the server 32. The applet 

which sets the characteristics of the already instantiated app.class in turn calls Constants.class, which is located in 



03/23/2004, EAST Version: 1.4.1 



US 6,6: 

17 

the same directory. Other pages are normal HTML pages, 
and thus contain no calls to the applet app, class. The pages 
which do contain the call to app .class may be in any 
directory on the server 32 which is able to access the first 
directory through a relative call. The first directory may also 
contain a file called update.txt. This file, when it is present, 
constitutes the database. 

The workstation 36 receives information from the server 
32 through the link 38. This link is essentially one-way. No 
data is ever sent from the workstation 36 to the server 32, 
other than a periodic call, initiated by the operator of the 
workstation 36, for page downloads, and a one-time attempt 
by the applet app.class to download the file update.txt. As 
indicated previously, the presence or absence of the file 
update.txt determines whether app .class operates with or 
without a database. 

In the shopping cart implementation of this invention, the 
operator of the workstation 36 sends information, when the 
operator wishes to finalize a purchase, through the second 
link 54 to the central server 56. Shopping cart information, 
stored in the workstation 36, is cleared when the data is sent 
through the link 54 to the central server 56. This ensures that 
link 54, like link 38, is essentially a one-way link — its 
precise nature is described in the next paragraph. 

As soon as the central server 56 has received sales 
information, then normal order processing takes place 
Between the central s erver i>6 and the workstation 36. This 
order processing is outside the scope of this invention. For 
instance, the central server 56 may send the workstation 36 
a summary of his purchases, and ask for name, a ddress, and 
credit card mtormation. The workstation ^0 may change his 
fflina at this point, press 4 RESET', restore the information in 
the cart, alter it, and resubmit. This still does not involve the 
central server 56. The previous page sent from the central 
server 56 is simply ignored, and responses are now made to 
the second page. It is in this precise fashion that the second 
link 54 is to be a one-way link. 

Now consider the exact nature of persistence. In 
particular, the process of storing, altering and retrieving a 
string variable will be considered. Suppose that the work- 
station 36 sends a request to the server 32 for a first page, 
Page 1. This page contains a call to launch app .class which 
resides in the first directory on the server 32, The file 
app .class, in response to this call, will be downloaded from 
the server 32 to the workstation 36, along with the classes, 
also residing in the first directory, to which the applet 
app.class refers. These must include at least one abstract 
class, which will be referred to as Constants .class. 

Let Constants.class contain the following global declara- 
tion: static String s="Hello";. In the general case, it is also 
possible to have the statement static String s; . Both options 
will work. 

The normal lifestyle of an applet determines that method 
start( ) in the applet app.class will be executed on the 
workstation 36 once the applet app.class has been fully 
loaded. Let this method contain the following line of code: 
String test=Constants.s; . If variable test is checked, it will 
be seen to contain the value "Hello." 

Suppose that an event occurs on the workstation 36 whose 
handler contains the following code: Constants.s«"Bye";. 
Executing the code String test=Constants.s will show that 
the variable test now contains the value "Bye," just as one 
would expect. 

Now suppose that the workstation 36 downloads a second 
page, Page 2 from the server 32. Page 2 may reside in a 
different directory than Page 1 — it is essential only that it 
refer to app.class in the first directory through a relative 
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address. (If the applet app.class is not referenced in the 
proper manner, then the call will set up a separate source of 
persistence. This can be a desired feature.) Page 2 may 
download the applet appxlass directly from the server 32, or 

5 it may load it indirecUy from a browser cache on the 
workstation 36 — it does not matter. 

As before, the abstract class Constants.class will be 
loaded with its global declaration static String s«"Hello";. 
However, if the code String test =Constants.s is now 

10 executed and the variable test is checked, it will be found to 
contain the string "Bye" and not "Hello." Thus, the change 
in the value has persisted from Page 1 to Page 2. This 
demonstrates the essential characteristic of persistence. 
Now suppose that the workstation 36 downloads an 

is HTML page which contains no code related to the applet 
app.class. The page may be located on the server 32, or it 
may be located on a totally different server. Next, suppose 
that either Page 1 or Page 2 is reloaded. If the code String 
test=Constants.s is executed and the variable test is 

20 displayed, it will still contain the value "Bye." This persis- 
tence will continue either until the browser on the worksta- 
tion 36 is closed, or until a number of pages with many JAVA 
applets are loaded. Notice again that there is no return traffic 
from the workstation 36 back to the server 32. Only requests 

25 for downloading information are passed from the worksta- 
tion 36 to the server 32. 

Now consider the preferred implementation of this inven- 
tion as a shopping cart. Suppose that Page 1 wishes to offer 
an item for sale. This is done by inserting the event handler 

30 onClick ^buy^itemlDVitemNameVitemPrice', 
'itemShippingProcedures')" into some object contained in 
Page 1. The strings in the event handler describe the item 
that is being sold. For instance, the event handler could have 
the form onClick«"buy('32\' Maple Butter*/ $43. 29', 'By 

35 Express Mail with tax*)", or possibly, onClick»"buy 
0A23C9\ 'French Horn',' $5,2007 17')". Note that the 
workstation 36 does not ask the server 32 what is for sale, 
and app.class itself contains no information about what is for 
sale. Instead, the specific information is hardcoded into Page 

40 1, Page 2, and so on. 

In the shopping cart implementation, the class 
Constants.class, which resides on the server 32 and was 
downloaded to the workstation 36, is expanded to include a 
Vector class which holds the sales information presented by 

45 the event handler. Each item that is purchased is allocated 
five fields in this one-dimensional Vector array — item ID, 
number of items purchased, item description, item price, and 
shipping instructions. The Vector class is defined in Con- 
stants.class through the statement Vector products=new 

50 Vector(lOO);. This allocates enough memory for 20 items. If 
more products are purchased, this Vector will automatically 
expand. 

When the shopper clicks the page object with its associ- 
ated event handler, then the method prod( ) is called in the 

55 applet app.class, which inserts the four string values con- 
tained in the onClick event handler, contained in Page Al, 
into the Vector in the class Constants.class, along with 
another string element containing the number of that item 
which is being bought. 

60 For efficiency, the method start( ) in one version of the 
applet app.class, called automatically by the browser when 
Page Alis loaded, will only instantiate the shopping cart 
frame when it sees that the size of the sales Vector in the 
class Constants.class is greater than zero. The state of this 

65 Vector is maintained by persistence. If the method prod( ) in 
the applet app.class, which method is called when there is a 
purchase, sees that the size of the sales Vector is zero, then 
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it begins its processing by instantiating the shopping cart 
frame. This refusal to instantiate the frame until necessary 
ensures optimal page access times. (This method of loading 
only an applet stub when there are no purchases works on 
every browser except INTERNET EXPLORER 3, which 5 
must be treated differently.) 

Alternatively, the shopping cart frame is instantiated 
immediately, but through an abstract class and a pseudo- 
constructor. The frame then remains active at all times, and 
becomes independent of the page — this means no delay time 1Q 
whatsoever between HTML accesses. As appropriate, the 
program simply switches the persistent frame between a 
visible and an invisible state. 

The shopping cart frame also contains buttons which 
allow the operator of the workstation 36 to modify the 
number of items being purchased. Each time a change is 15 
made, an appropriate method in the dependent class 
Constants.class, is called. The shopping carl frame is 
updated appropriately. As the client continues to browse, 
persistence of data is maintained through the Vector class. 
The frame remains visible — in one implementation because 20 
it is re -instantiated after every page transfer, in the other 
because of the initial use of pseudo-constructors. 

One of the buttons on the shopping cart frame provides an 
' option to order the items currently selected. When this 
button is clicked, then the dependent class Constants.class, 25 
initiates a jump from the workstation 36 to the central server 
56. The information in the Vector class is appended as 
name-value pairs to the HTTP address of the central server 
56 — to a maximum of 900 bytes of information, which is all 
that is allowed by the JAVA Virtual Machine — and the sales 30 
Vector is cleared correspondingly. Included with the infor- 
mation in the HTTP address is the codebase of the applet 
app.class on the server 32, which is used by the central 
server 56 to identify the site of the merchant. 

When the applet app.class, with its associated classes, is 35 
first launched by the workstation 36, it attempts to download 
a file update.txt from the first directory in the server 32. If 
the file is absent, then a Boolean class is set in the class 
Constants.class, and the applet app.class knows not to try 
again. The Boolean class is set only when downloading is 40 
fully complete. Thus, if a page transfer, say from Page 1 to 
Page 2, is made while the download is in process, then the 
Boolean variable will not be set, and the applet app.class will 
repeat the download attempt when it is launched by Page 2. 
All intermediate variables involved in downloading 45 
update.txt are non-static, so that a re- attempt to download 
this file will not be disturbed by unwanted persistence. 

Once downloading of the file update.txt is fully complete, 
then its data is transferred permanently to a static String 
variable in the class Constants.class, which is running on the 50 
workstation 36. JAVA String search functions are used to 
provide fast access to desired values. If Page Al, loaded 
from the server 32 and now residing on the workstation 36, 
contains an event handler which offers an item for sale, and 
the event handler is triggered by the operator of the work- 55 
station 36, and a database is present as a static String in the 
class Constants.class, then the call to method prod( ) in the 
applet app.class will include a check to see whether the ID 
that is present in the HTML event handler call from Page 1 
is listed in the database String in the class Constants.class. 60 
If it is, then the database price in the String is used rather 
than the amount hard- wired into the event handler in Page 1. 

Although the invention has been disclosed in terms of a 
number of preferred embodiments, and variations thereon, it 
will be understood that numerous additional modifications 65 
and variations could be made without departing from the 
scope of the invention as set forth in the following claims. 
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What is claimed is: 

1. A method for generating persistence among a plurality 
of web pages comprising the steps of: 

a) providing a computing device including a memory, a 
browser application, and a software engine associated 
with said browser application; 

b) providing at least first and second codes that are 
employed to generate first and second web pages, 
respectively, each of said codes including a first and a 
second subset, said first code subset defining a program 
to be accessed and including identification information 
for said program, said program including a plurality of 
static variables that remain defined as long as said 
program remains loaded in said memory by said 
browser-associated software engine, each of said vari- 
ables having a corresponding value, and said second 
code subset comprising program code that facilitates 
access and modification of said static variables with 
said browser- associated software engine through said 
web pages; 

c) loading said first code in said memory of said com- 
puting device; 

d) accessing said first code of said first web page with said 
browser application; 

e) executing said program with said browser-associated 
software engine; 

f) employing said browser-associated software engine 
facilitated by said second code subset to modify said 
static variables in said program; 

g) suspending said program without unloading said pro- 
gram from said memory by ceasing access of said first 
code of said first web page; 

h) loading said second code in said memory of said 
computing device; 

i) accessing said second code of said second web page 
with said browser application; 

j) employing said program identification information in 
said first code subset of said second code to reactivate 
said program with said browser-associated software 
engine using the values of said static variables as they 
were prior to said program being suspended; and 

k) employing said browser-associated software engine 
facilitated by said second code subset to access the 
values of said static variables in said program; 

whereby, said program performs a function with both said 
first and said second web pages. 

2. The method of claim 1, wherein said program is 
selected from the group comprising a JAVA applet and an 
Active X object. 

3. The method of claim 1, wherein at least some of said 
static variables comprise a database or a database cache. 

4. The method of claim 1, wherein at least some of said 
static variables contain quantity and price information for 
one or more items selected for purchase from information 
provided in said first and second web pages. 

5. The method of claim 1, wherein said program subset 
further includes at least one parameter that can be altered 
from one web page to another, without altering the identity 
of said program, whereby, said program can be made to run 
differently, depending on the web page currently loaded in 
said memory. 

6. The method of claim 1, wherein said first and second 
codes are loaded from a storage device selected from the 
group comprising a hard drive, a CD-ROM, a remotely 
located server and a local server. 
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7. The method of claim 1, wherein at least some of said 
plurality of static variables that remain defined as long as 
said first program remains loaded in said memory by said 
browser-associated software engine arc used to generate an 
object that remains active as long as said first program 
remains loaded in said memory by said browser-associated 
software engine regardless of whether code that was loaded 
in said memory when said object was created continues to be 
loaded. 

. 8. The method of claim 7, wherein said object is a 
graphical user interface that is displayed on a display 
associated with said computing device. 

9. The method of claim 7, wherein said object is a visual 
object that is displayed on a display associated with said 
computing device. 

10. The method of claim 7, wherein said object commu- 
nicates with a database. 

11. The method of claim 7, wherein said object is a 
database cache. 

12. A computer device for accessing a program to be 
associated with a plurality of web pages comprising: 

a) a processor; 

b) an operating memory; 

c) a browser application; and 

d) a software application associated with said browser 
application, 

said processor being programmed with said a software 
engine to: 

1) load in said memory, a first of first and second 
codes that are employed to generate first and 
second web pages, respectively, each of said codes 
including a first and a second subset said first 
subset defining a program to be accessed and 
including identification information for said 
program, said program including a plurality of 
static variables that remain defined as long as said 
program remains loaded in said memory by said 
browser-associated software engine, each of said 
variables having a corresponding value; and said 
second subset comprising program code that 
facilitates access and modification of said static 
variables with said browser-associated software 
engine through said web pages; 

2) access said first code of said first web page with 
said browser application; 

3) execute said program with said browser- 
associated software engine; 

4) suspend said program without unloading said 
program from said memory by ceasing access of 
said first code of said first web page; 

5) load said second code in said memory; 

6) access said second code of said second web page 
with said browser application; 

7) employ said program identification information in 
said first code subset of said second code to 
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reactivate said program using the values of said 
static variables as they were prior to said program 
being suspended; and 
8) employ said browser- associated software engine 
facilitated by said second code subset to access the 
values of said static variables in said program; 
whereby, said program performs a function with 
both said first and said second web pages. 

13. The computer device of claim 12, wherein said 
program is selected from the group comprising a JAVA 
applet and an Active X object. 

14. The computer device of claim 12, wherein at least 
some of said static variables comprise a database or a 
database cache. 

15. The computer device of claim 12, wherein at least 
some of said static variables contain quantity and price 
information for one or more items selected for purchase 
from information provided in said first and second web 
pages. 

16. The computer device of claim 12, wherein said first 
subset further includes at least one parameter that can be 
altered from one web page to another, without altering the 
identity of said program, whereby, said program can be 
made to run differently, depending on the web page currently 
loaded in said memory. 

17. The computer device of claim 12, further including a 
storage device selected from the group comprising a hard 
drive, a CD-ROM, a remotely located server and a local 
server for storing said first and second codes before they are 
loaded into said operating memory. 

18. The method of claim 12, wherein at least some of said 
plurality of static variables that remain defined as long as 
said first program remains loaded in said memory by said 
browser-associated software engine are used to generate an 
object that remains active as long as said first program 
remains loaded in said memory by said browser-associated 
software engine, regardless of whether code that was loaded 
in said memory when said object was created continues to be 
loaded. 

19. The computer device of claim 18, wherein said object 
is a graphical user interface that is displayed on a display 
associated with said computing device. 

20. The computer device of claim 18, wherein said object 
is a visual object that is displayed on a display associated 
with said computing device. 

21. The computer device of claim 18, wherein said object 
communicates with a database. 

22. The computer device of claim 18, wherein said object 
is a database cache. 

23. The computer device of claim 18, wherein said object 
contains quantity and price information for one or more 
items selected for purchase from information provided in 
said first and second web pages. 
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